Payment transactions using payee account aliases

ABSTRACT

Embodiments of the invention provide a system and method for using aliases, such as mobile telephone numbers, email addresses, and social networking identifications, to identify a payment recipient&#39;s account involved in a payment transaction. Some embodiments of the method include: (1) receiving a payment request from a payment sender via a communication from a remote device, where the payment request includes an alias, and where the alias is not an account number; (2) using a processor to identify a payment recipient&#39;s financial account based at least partially on the alias; and (3) transferring funds from the payment sender&#39;s account to the payment recipient&#39;s account. Identifying the payment recipient&#39;s financial account based on the alias may include accessing a memory device having a data repository stored therein that maps each of a plurality of aliases back to a financial account number, and then using the data repository in combination with the alias to identify the payment recipient&#39;s financial account number.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of and claims priority fromco-pending U.S. patent application Ser. No. 12/038,177, filed on Feb.27, 2008 and entitled “SUB-ACCOUNT MECHANISM,” which claims priorityfrom U.S. Provisional Patent Application No. 60/991,172, filed on Nov.29, 2007 and entitled “SUB-ACCOUNT MECHANISM,” the entire contents ofboth of these applications are hereby incorporated herein by reference.

BACKGROUND

Today, individuals, such as parents, do not have an easy and seamlessprocess to manage and dispense money to their dependents. Besidesmanaging and controlling their dependents spending activities, safety independents carrying large amounts of cash may be a concern for parents.

Dependents are increasingly purchasing goods and services on-line wherethey cannot use cash but need a payment card. Since they may not havetheir own direct deposit account (DDA) or credit card account, theycannot use traditional methods of payment for this channel to purchasegoods. At the physical point of service (POS), dependents generally usecash to make their purchases, which excludes financial entities from thepayment transactions and associated revenues. In addition, merchantsthat sell digital media, e.g., music, movies, videos, etc., do not havea low cost micropayment solution.

Today, individuals and dependents may attain prepaid cards such as theAllowcard® and the American Express Gift Card for Teens® to use towardson-line purchases or physical retailers. Another alternative is using aparent's credit card where there are no controls on dependents spendingactivities. For physical retailers, the majority of purchases bydependents is made using cash or “additional” credit cards. Credit cardsissued by competitors and cash as payment instruments remove financialentities from payments revenue.

ECommerce merchants whose business requires micropayments are currentlydependent on credit/debit card transactions for payment. These companiesare looking for processes that reduce their payment expense.

In addition, individuals may want to budget their resources acrossdifferent financial needs. For example, a family may decide that amonthly income of $2000 may need to be budgeted for known and otherexpenses. The family may decide to restrict use of the monthly income toonly $100 for gas, $100 a month for clothing items, $100 a month forentertainment items/services, and $200 a month for food items/services.In such a case, the family must maintain detailed records of who isspending what, where, when, and under what category.

A financial entity currently allows its customers to make payments toother financial entity customers through its online banking service. Inorder to make a payment, the sender has to ask receiver to provide theirbank account number and zip code. The receiver needs to share thisconfidential account information in order to be able to get a payment.In addition, both the sender and receiver need to be customers of thefinancial entity. It is not possible for financial entity customers tosend payments to anyone outside the financial entity or make payments tomerchants directly from their bank accounts.

Person to person and person to merchant payments are not unique. Thereare number of companies like PayPal, OboPay, Revolution Money and othersthat allow their customers to make payments using a stored value card ora pooled account. The stored value card or a pooled account is like aprepaid or a gift card and it exists separately from customer's bankaccounts. The customer has to move money into this account throughautomated clearing house (ACH) transfer or credit card cash advancebefore these can be used to make payments. It typically takes 2-3business days to move money into such accounts.

There are currently no practical and cost-effective systems that canprovide a seamless integration of a master DDA, one or moresub-accounts, and merchant client accounts.

SUMMARY

In light of the foregoing background, the following presents asimplified summary of the present disclosure in order to provide a basicunderstanding of some aspects of the invention. This summary is not anextensive overview of the invention. It is not intended to identify keyor critical elements of the invention or to delineate the scope of theinvention. The following summary merely presents some concepts of theinvention in a simplified form as a prelude to the more detaileddescription provided below.

Aspects of the present invention are directed to a method and system forproviding a seamless integration of a master DDA, one or moresub-accounts, and merchant client accounts. Aspects of the presentdisclosure are directed to establishment of a monetary account with anentity. An account user associated with the monetary account may beidentified. A sub-account with the entity may be established, where thesub-account is associated with the monetary account and includesmonetary funds transferred from the monetary account. At least onesub-account user associated with the sub-account may be identified,where the at least one sub-account user is different from the accountuser. One or more controls, placed by the account user, may beestablished on at least one of the sub-account and the at least onesub-account user. The at least one sub-account user may be restrictedfrom accessing monetary funds in the monetary account and the accountuser is permitted to access the sub-account.

Another aspect of the present disclosure is directed to establishing amonetary account with an entity, the monetary account including monetaryfunds maintained within the entity. An account user associated with themonetary account may be identified, and a partner account, with theentity, a partner entity of the entity, the partner account includingmonetary funds maintained within the entity. A request from the accountuser to transfer monetary funds from the monetary account to the partneraccount through a website associated with the partner entity may bereceived. The monetary funds may be transferred from the monetaryaccount to the partner account, where the monetary funds remain withinthe entity throughout the transfer.

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. The Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used to limit the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of aspects of the present invention andthe advantages thereof may be acquired by referring to the followingdescription in consideration of the accompanying drawings, in which likereference numbers indicate like features, and wherein:

FIG. 1 illustrates a schematic diagram of a general-purpose digitalcomputing environment in which certain aspects of the present inventionmay be implemented;

FIG. 2 is an illustrative block diagram of workstations and servers thatmay be used to implement the processes and functions of certainembodiments of the present invention;

FIG. 3 is an example block diagram of an illustrative environment forapplying a master account and associated sub-accounts in accordance withat least one aspect of the present invention;

FIG. 4 is another example block diagram of an illustrative environmentfor applying a master account and associated sub-accounts in accordancewith at least one aspect of the present invention;

FIG. 5 is another example block diagram of an illustrative environmentfor applying a master account and associated sub-accounts in accordancewith at least one aspect of the present invention;

FIG. 6 is an example flowchart of an illustrative method for applying amaster account and associated sub-accounts in accordance with at leastone aspect of the present invention;

FIG. 7 is an illustrative user interface for maintaining a masteraccount and sub-accounts with respect to a merchant in accordance withone or more aspects of the present invention;

FIG. 8 is an example flowchart of a method for making person to personpayments in accordance with one or more aspects of the presentinvention;

FIG. 9 is an example flowchart of a method for making payments from amobile device in accordance with one or more aspects of the presentinvention; and

FIG. 10 is an example flowchart of a method for making payments to amerchant in accordance with one or more aspects of the presentinvention.

DETAILED DESCRIPTION

In the following description of the various embodiments, reference ismade to the accompanying drawings, which form a part hereof, and inwhich is shown by way of illustration various embodiments in which theinvention may be practiced. It is to be understood that otherembodiments may be utilized and structural and functional modificationsmay be made.

FIG. 1 illustrates a block diagram of a generic computing device 101(e.g., a computer server) that may be used according to an illustrativeembodiment of the invention. The computer server 101 may have aprocessor 103 for controlling overall operation of the server and itsassociated components, including RAM 105, ROM 107, input/output module109, and memory 115.

I/O 109 may include a microphone, keypad, touch screen, and/or stylusthrough which a user of device 101 may provide input, and may alsoinclude one or more of a speaker for providing audio output and a videodisplay device for providing textual, audiovisual and/or graphicaloutput. Software may be stored within memory 115 and/or storage toprovide instructions to processor 103 for enabling server 101 to performvarious functions. For example, memory 115 may store software used bythe server 101, such as an operating system 117, application programs119, and an associated database 121. Alternatively, some or all ofserver 101 computer executable instructions may be embodied in hardwareor firmware (not shown). As described in detail below, the database 121may provide centralized storage of account information and accountholder information for the entire business, allowing interoperabilitybetween different elements of the business residing at differentphysical locations.

The server 101 may operate in a networked environment supportingconnections to one or more remote computers, such as terminals 141 and151. The terminals 141 and 151 may be personal computers or servers thatinclude many or all of the elements described above relative to theserver 101. The network connections depicted in FIG. 1 include a localarea network (LAN) 125 and a wide area network (WAN) 129, but may alsoinclude other networks. When used in a LAN networking environment, thecomputer 101 is connected to the LAN 125 through a network interface oradapter 123. When used in a WAN networking environment, the server 101may include a modem 127 or other means for establishing communicationsover the WAN 129, such as the Internet 131. It will be appreciated thatthe network connections shown are illustrative and other means ofestablishing a communications link between the computers may be used.The existence of any of various well-known protocols such as TCP/IP,Ethernet, FTP, HTTP and the like is presumed, and the system can beoperated in a client-server configuration to permit a user to retrieveweb pages from a web-based server. Any of various conventional webbrowsers can be used to display and manipulate data on web pages.

Additionally, an application program 119 used by the server 101according to an illustrative embodiment of the invention may includecomputer executable instructions for invoking user functionality relatedto communication, such as email, short message service (SMS), and voiceinput and speech recognition applications.

Computing device 101 and/or terminals 141 or 151 may also be mobileterminals including various other components, such as a battery,speaker, and antennas (not shown).

The invention is operational with numerous other general purpose orspecial purpose computing system environments or configurations.Examples of well known computing systems, environments, and/orconfigurations that may be suitable for use with the invention include,but are not limited to, personal computers, server computers, hand-heldor laptop devices, multiprocessor systems, microprocessor-based systems,set top boxes, programmable consumer electronics, network PCs,minicomputers, mainframe computers, distributed computing environmentsthat include any of the above systems or devices, and the like.

The invention may be described in the general context ofcomputer-executable instructions, such as program modules, beingexecuted by a computer. Generally, program modules include routines,programs, objects, components, data structures, etc. that performparticular tasks or implement particular abstract data types. Theinvention may also be practiced in distributed computing environmentswhere tasks are performed by remote processing devices that are linkedthrough a communications network. In a distributed computingenvironment, program modules may be located in both local and remotecomputer storage media including memory storage devices.

Referring to FIG. 2, an illustrative system 200 for implementing methodsaccording to the present invention is shown. As illustrated, system 200may include one or more workstations 201. Workstations 201 may be localor remote, and are connected by one or communications links 202 tocomputer network 203 that is linked via communications links 205 toserver 204. In system 200, server 204 may be any suitable server,processor, computer, or data processing device, or combination of thesame. Server 204 may be used to process the instructions received from,and the transactions entered into by, one or more participants.

Computer network 203 may be any suitable computer network including theInternet, an intranet, a wide-area network (WAN), a local-area network(LAN), a wireless network, a digital subscriber line (DSL) network, aframe relay network, an asynchronous transfer mode (ATM) network, avirtual private network (VPN), or any combination of any of the same.Communications links 202 and 205 may be any communications linkssuitable for communicating between workstations 201 and server 204, suchas network links, dial-up links, wireless links, hard-wired links, etc.

As understood by those skilled in the art, the steps that follow in theFigures may be implemented by one or more of the components in FIGS. 1and 2 and/or other components, including other computing devices.

Aspects of the present disclosure allow a financial entity to capturemore cash-to-card payment volume and provide partners to the financialentity a reduction in payment expense. A company has the ability tobring users to a financial entity and can partner with the financialentity to create an affinity relationship and product.

The integration of companion cards, whether debit or stored value, tosub-accounts and a master direct deposit account (DDA) is described. Thecompanion cards do not have access to the master DDA, which allows theprimary account holder to have complete control over spending activitiesof the sub-accounts. The primary account holder can transfer fundsbetween the master DDA and sub-accounts through her preferred channel ofbanking, e.g., automated teller machine (ATM), online banking, mobilebanking, etc. Until the money is spent using the companion cards,deposit balances remain in the sub-accounts, which keep the funds in thefinancial entity banking system. Also, the companion card enables afinancial entity to capture new payment transactions where cash may havebeen used previously.

Additionally, when a customer of a financial entity makes a purchaseon-line from a partner of the financial entity, the payment may belinked to the sub-accounts described above. The deposits may be movedfrom the consumer's sub-account to the affinity partner's corporateaccount real-time. This process is more cost efficient for the affinitypartners since it optimizes transaction routing. Also, deposit balancesremain in the financial entity banking system. This account to accounttransfer process is a faster and cheaper method of processing paymentsfor affinity merchants.

Aspects of the present disclosure integrate the dependent paymentinstrument, e.g., companion card, to the sub-accounts of the master DDAwithout allowing access to the master DDA by users of the sub-accounts.

Traditional transactions using prepaid cards decreases balances, byremoving money deposited in the bank, even before actual purchasetransactions are made. This situation decreases the cash amountremaining in the bank, thus decreasing a source of revenues for banks.Additionally, using cash as a payment instrument also decreasesbalances, another source of bank revenues.

Aspects of the present disclosure address the above problems and createsnew revenue streams for a financial entity through an increase of pointof service (POS) transactions by shifting payment instrument from cashto debit or stored value cards at the physical retailer. At the sametime, this concept creates the incremental DDA balances by delaying thewithdrawal of funds until spending activity. The system also provides aninstantaneous control mechanism for the primary DDA holder to track andcontrol spending activities made by dependents.

Furthermore, aspects of the present disclosure allow eCommerce partnersin the micropayment business to have a more cost-effective process tosettle their payment transactions through the system. For customers of afinancial entity, the financial entity may optimize transaction routingfor payment processing real-time. The consumer account of the financialentity may be debited much like a debit card transactions while theaffinity partner's business client account may be credited. Thus, fundsstay in the banking system of the financial entity.

The integration of companion cards to sub-accounts directly linked to aDDA is an aspect of the present disclosure. In addition, optimizingtransaction routing for eCommerce affinity partners is another aspect.For transactions between affinity merchants of a financial entity andcustomers of the financial entity, the financial entity may identifythese payment transactions and process them in the lowest cost manner.The financial entity may use account to account transfer mechanism tomove money from the customer to the merchant instead of the traditionalpayment processes using the credit/debit/ACH network (described below inFIG. 5). In one embodiment, the financial entity may determine pricingfor the account to account transfer mechanism that will be costeffective for the merchant.

As should be understood by those skilled in the art, variouscombinations and sub-combinations of the descriptions included hereinmay be utilized absent the illustrative example provided. For example,in accordance with one or more aspects of the present disclosure, thereis no requirement in place to mandate a user to open a master accountwith a financial entity before a sub-account may be opened. A personusing an account with a merchant that is linked to the financial entityis able to open a sub-account anytime without first having to apply fora master DDA with the financial entity. In such a situation, thesub-account is an account of the user in which the user does not haveother accounts affiliated with the financial entity. As such, themerchant, such as a media downloading web site, may have a link to opensuch a sub-account with the financial entity. In addition, a personreceiving payment who does not have a sub-account may open one to getaccess to those funds. A P2P/P2M account may be such an opened account.A P2P/P2M account described herein may exist on its own.

FIG. 3 is an example block diagram of an illustrative environment 300for applying a master account and associated sub-accounts in accordancewith at least one aspect of the present invention.

A customer 301 has access to a master direct deposit account (DDA) 303through any of a number of different channels of communication,including, but not limited to, online banking, mobile banking, and ATM,shown by A. Customer 301 may make money transfers between the master DDA303 and one or more sub-accounts, such as sub-account 1 305 andsub-account 2 307 without any cost, shown by B.

One or more companion cards, such as companion card 1 313 and companioncard 2 315, are linked to the sub-accounts, as shown by C, and cannotaccess deposits in the master DDA 303. This allows the customer/primaryaccount holder to have control of the level of spending activities madeby both the existing debit cards 311 and all companion cards 313 and315.

Companion cards 313 and 315 may be used for eCommerce with non-entitymerchants and entity non-affinity merchants 317, at a physical POS andat ATMs in the same manner that the primary cardholder debit card 311 isused, as shown by D. For eCommerce businesses that have an affinitypartnership with the financial entity 309, payments between an entityconsumer and merchant may be processed real-time and transaction routingmay be optimized, as shown by E. FIG. 5 provides further details below.

FIG. 4 is another example block diagram of an illustrative environment400 for applying a master account and associated sub-accounts fornon-financial entity merchants and financial entity non-affinitymerchants in accordance with at least one aspect of the presentinvention. A customer may make money transfers between a master DDA 401and one or more sub-accounts, such as sub-account 1 403 and sub-account2 405, without any cost, as shown by B.

One or more companion cards, such as companion card 1 409 and companioncard 2 411, are linked to the sub-accounts 403 and 405, as shown by C,and cannot access deposits in the master DDA 401. This allows thecustomer/primary account holder to have control of the level of spendingactivities made by both the existing debit cards 407 and all companioncards 409 and 411. Companion cards 409 and 411 may be used for eCommerce413, at a physical POS 415 and at ATMs 417 in the same manner that theprimary cardholder debit card 407 is used, as shown by D. Transactionsmay be processed through a debit, credit, or ATM network.

FIG. 5 is another example block diagram of an illustrative environment500 for applying a master account and associated sub-accounts forfinancial entity affinity merchant partners 507 in accordance with atleast one aspect of the present invention. A customer may make moneytransfers between a master DDA 501 and one or more sub-accounts, such assub-account 1 503 and sub-account 2 505, without any cost, as shown byB. For eCommerce businesses 507 that have an affinity partnership withthe financial entity, payments between consumers and merchants of thefinancial entity are processed real-time and transaction routing isoptimized, as shown by E. The real-time payment may initiate moneytransfer between the financial entity consumer account 501 orsub-account, such as 503 and 505, and the merchant 507 corporateaccount, where the merchant account is credited 509 and the consumeraccount is debited 511, as shown by F. A small processing fee may becharged to the merchant 507.

FIG. 6 is an example flowchart 600 of an illustrative method forapplying a master account and associated sub-accounts in accordance withat least one aspect of the present invention. Various web interfaces 601may be utilized in accordance with aspects of the present invention.Customers may work with and access master accounts and sub-accounts viamobile banking 603, online banking application 605, and/or merchantaccount 607. A customer may have a master account, such as master DDA609, associated with a financial entity. The master account 609 mayinclude a plurality of sub-accounts. As shown, master account 609includes sub-account 1 611, sub-account 2 613, and sub-account 3 615.sub-accounts 611, 613, and 615 may be restricted child accounts with oneor more parental controls in place.

As described herein, there may be any of a number of different controlson a sub-account and different controls may be placed on differentaccounts. Controls include the ability to transfer funds out of thesub-account, whether the amount, to the particular recipient, to aparticular time period, etc. Controls also include the ability toreceive funds into the sub-account, whether from particular individualsor entities, the amount, to a particular time period, etc. Controlsfurther may include other functions associated with the accountincluding ability to change access passwords or IDs, ability to allowothers to access the sub-account, and ability to restrict others fromaccessing the sub-account.

The master account 609 and one or more of the sub-accounts 611, 613, and615, may have access mechanisms in place, such as a debit card 619, oneor more companion cards 621, and a user ID and password 623. The accessmechanisms allow for purchases to web pages 625, other eCommerce 627,ATMs 629 and point of service device 631, such as telephone orders. Withthe controls in place, any of a number of different restrictions may beplaced on a sub-account. For example, sub-account 611 may be for asixteen year old minor while sub-account 613 may be for a twelve yearold minor. A parent of the master account 609 may allow the sixteen yearold to access certain web sites 625 or an ATM 629 while restricting thetwelve year old from the same. With controls in place on thesub-accounts, the twelve year old associated with the sub-account 613cannot access the restricted web sites 625 and/or ATMs 629. Any of anumber of different controls schemes may be in place with respect to thesub-accounts. The examples included herein are merely illustrative andshould not be limited to the same.

FIG. 7 is an illustrative user interface 700 for maintaining a masteraccount and sub-accounts with respect to a merchant in accordance withone or more aspects of the present invention. A user profile for acustomer of a financial entity 711 is shown with respect to a particularmerchant 713. As shown, various data fields are included to input dataand to see current data. Data field 701 allows a user to enter accountowner information, such as name, address, etc. Data field 703 allows theuser to enter additional account owner data including user ID, cellularphone number, and email address. Data field 705 allows the user to entera password or web site key.

Data field 707 includes card number data, such as an account number andan expiration date, for an account number associated with a masteraccount of the user. Data field 709 includes a listing of individualsand corresponding information for one or more sub-accounts associatedwith that account. Data field 715 shows merchant account balanceinformation. Data field 717 shows financial entity and non-financialentity account data for funding accounts. Input 719 allows a user to addfunds to an account in which one or more other screens may be provided.Input 721 allows a user to transfer funds to a friend in which one ormore other screens may be provided.

A parent may manage one or more children sub-accounts from the parent'smaster account. As part of the parent account, the parent can see all ofher accounts associated with the master account in addition to thesub-accounts. The parent may transfer funds form one or more of heraccounts in the master account to one or more of the children'ssub-accounts through any of a number of different interfaces. An emailmay be sent to the child to inform them of the transfer. The child mayaccess a web site, such as a music downloading website, to see the newnet balance on his child sub-account. Alternatively, the child may seethe balance by directly accessing the web site or online banking of thefinancial entity. If not restricted by control mechanisms describedherein, the child may immediately purchase music from the musicdownloading website from funds in the child's sub-account. In anotherembodiment, the child may request funds through an interface associatedwith the financial entity and/or a particular merchant web site.

Further aspects of the present disclosure describe a payment product foronline banking integrated person to person (P2P) and person to merchant(P2M) payments that allows customers of a financial entity to makepayments directly from their bank accounts, whether checking, savings,line of credit, credit card and other accounts, to anyone, includingnon-financial entity customers, without having to share any confidentialaccount information. The product may be used to make payments toconsumers as well as merchants.

The person to person and person to merchant payment product allowscustomers to make payments to anyone, consumers and merchants, directlyfrom their financial entity accounts. Currently no other entity offerssuch a product that allows payments directly from bank accounts. Inaddition, this process results in non-financial entity customers to opena new type of checking account, for P2P/P2M use, with the financialentity in order to receive their funds. Currently no other entity offerssuch a viral bank account opening process.

This product also lets the customers of the financial entity open aP2P/P2M account and use it for making payments or send money to minorswho currently cannot open their own accounts, creating a separateP2P/P2M account that will have funds for the minor. The minor may onlyaccess this P2M/P2M account especially set up for them whereas theparents will have full access to the P2P/P2M account in addition totheir own account(s) at the financial entity. Currently such an account,which parents can access along with their other regular accounts butwhere minors can only access the account set up for them, is also notoffered.

The product described below will allow its customers to make P2Ppayments to anyone. FIG. 8 is an example flowchart of a method 800 formaking person to person payments in accordance with one or more aspectsof the present invention. A customer 801 with an eligible account 807,e.g., checking (DDA), savings, line of credit, credit card, of afinancial entity is be able to register and make use of this service.During the registration process, the customer 801 is able to set up anAlias ID 817 that maps back to their online banking ID and optionallyalso provide one or multiple additional unique identifiers, e.g., mobilenumber 819, email address 821, social networking ID 823. The informationprovided by the customer 801 may be verified to confirm that they dohave access to the mobile number 819, email address 821, or socialnetworking ID 823 provided. Once the information is verified, then itwill be linked to their online banking ID, i.e., to all of theirfinancial entity accounts. If outgoing payments are not received by areceiver in 803, payment may be canceled in 805.

Customer 801 also is able to set preferences for accounts to be used foroutgoing payments, default account(s) for incoming payments, andalternatively also has an option of opening a new financial entityP2P/P2M account 809 that she may use for making payments. This financialentity P2P/P2M account 809 may be like any other account hosted at thefinancial entity and so money may be moved instantly into this account809 through the regular online banking transfer process for moving moneybetween accounts. This account 809 may be a type of checking accountexcept that it may come with certain limitations, e.g. no checks,maximum balance limits, number of daily transactions, and may be openedby customers by providing much less information as compared to a regularchecking account. The financial entity may, at minimum, requirecustomers to provide certain information, such as name, address, date ofbirth, and social security number, in order to comply with Anti-MoneyLaundering regulations.

Customers 801 of the financial entity also have an option to set upP2P/P2M accounts 809 for minors 825. Customers 801 are able to accessthese accounts just like any of their other accounts. In addition,customer 801 are able to set up an online banking access ID for theminor 825 that the minor 825 may use to sign into online banking buthave access only to the specific minor P2P/P2M account 809 set up forthem.

Customers 801 of the financial entity are able to make payments to otherpeople through any of a number of different methods. Payments may bemade by a routing number/account number 813. Payments may also be madeby providing an account number or zip code 815. If there is a match toan existing financial entity account in 827, then the funds aretransferred instantly to that account. Else, an error message 829 may begenerated. Payments may be made by providing an Alias ID 817. If thereis a match to an Alias ID of another customer in 831, then payment maybe initiated to that person. Else, an error message 829 may begenerated.

If the receiver has set up default account(s) for incoming payments in837, then the funds may be transferred instantly to that account(s). Ifthe receiver has not set up a default account in 837, then the funds maybe moved to a master settlement account 835 and the receiver may see thepayment as an incoming payment within online banking 833. The receivermay then be able to move instantly the funds to any of their accounts.

Payment may be made by providing a mobile phone number. This operationmay perform exactly as described above for Alias ID if there is a matchin 839 on the mobile number. If there is no match in 839, then a textmessage may be sent to the mobile number provided. If the receiver ofthe message is an existing financial entity online banking customer,then that person may be allowed to sign into their online bankingaccount 841, register the phone number, and then receive funds similarto the process described above for Alias ID. If the receiver is afinancial entity customer who is not registered for online banking, thenthat customer may be able to register 851 for online banking and accessfunds following the same process as described above. If the receiver isnot a financial entity customer with an account eligible for receivingfunds, then they may be given the option to sign up 851 for a P2P/P2Maccount 843 at the financial entity that they can access through onlinebanking or return funds to the sender 853.

After completion of registration 851, the receiver 849 may get access tothe funds from this account. Subsequently the receiver may keep thefunds in the account or add more funds from an external bank account 845using the financial entity's existing ACH transfer capability and thenuse the funds to make P2P/P2M payments to others. They will also havethe option to move the funds to their external bank account 845 anytimemaking use of the financial entity's existing ACH transfer capability.

Payment also may be made by providing an email address 821. Thisoperation may perform exactly as described above for a mobile number 819except that the message may be sent to the email address input by thesender. Payment may be made by providing a social networking ID 823. Thefinancial entity may extend availability of this product to varioussocial networking platforms. In that situation, the process operates inthe same way as described above for mobile phone number 819 and emailaddress 821 except the social networking platform may be used to notifythe receiver based on the social networking ID 823 provided by thesender. In this situation, if the receiver is not a financial entitycustomer, then she may be given the option to sign up 851 for a P2P/P2Maccount 843 at the financial entity, which she may access through onlinebanking to access the funds sent to them. The financial entity P2P/P2Maccount 843 may include a companion ATM/debit card 847.

In all cases described above, if the receiver is already a registeredP2P/P2M customer at the financial entity, a text message and/or emailmay be sent to that customer irrespective of information entered bysender if there is one found in their profile.

FIG. 9 is an example flowchart of a method 900 for making payments froma mobile device in accordance with one or more aspects of the presentinvention. A customer 901 who is signed up for the service has theoption to initiate payment from a DDA, savings, line of credit, and/orcredit card of the financial entity 903 and/or from a P2P/P2M account905 through the financial entity's mobile banking web site 909 or amobile banking handset application 907 downloaded on the phone byproviding any of the above information, e.g., phone number, emailaddress, Alias ID, social networking ID. Customers also are able toinitiate payments by sending a text message 911 to the financial entitythat contains the receiver's phone number, email address, Alias ID, orsocial networking ID. Whether via a mobile banking handset application907, mobile web site 909, or short message service 911, a receiverassociated with the financial entity 917 may receive funds at her DDA,savings, etc. 913 and/or P2P/P2M account 915. A receiver not associatedwith the financial entity 921 may receive funds at her P2P/P2M account919.

FIG. 10 is an example flowchart of a method 1000 for making payments toa merchant in accordance with one or more aspects of the presentinvention. For all customers 1001 who are signed up for the service, thefinancial entity lets them create a unique shopping ID and password 1005linked to each of their accounts which may be used to make purchases atmerchant 1019 web sites 1013. Such customers 1001 are able to inputtheir shopping ID and shopping password 1005 on any merchant's 1019 website 1013 who has signed up for the service. Upon successful validationof the credentials and if the customer 1001 has sufficient funds intheir account, the money may instantly be transferred from thecustomer's account 1007 and/or 1009 to the merchant's checking account1017. Alternatively, the financial entity may offer merchants 1019 theability to consolidate such payments 1015 and receive one lump sumpayment from the financial entity.

Customers will also have ability to link their bank accounts to any NearField Communications (NFC) enabled phone 1003. In that situation,customers 1001 may initiate instant movement of funds 1011 from theirfinancial entity account 1007 and/or 1009 to the merchant 1019 fromtheir phone 1003. In accordance with some aspects, the customer may havea non-NFC enabled phone. In such a situation, a merchant 1019 may key inthe customer's phone number in a cash register or other computingdevice. The customer then may be alerted about the payment amount on herphone. The customer may authenticate, such as by use of a personalidentification number (PIN) or scanning of a fingerprint of thecustomer, to ensure that the phone has not been stolen and that mayauthorize the payment. In accordance with other aspects, a customer whouses her companion card at a retailer, such as a branded coffee café,immediately may receive a receipt on her phone and, at the same time,may be prompted on her phone to make additional purchases, such as at amedia store on the Internet or a discount offer on a certain product.

The customers may be given an option to open multiple P2P/P2M accounts1009 and use those for different needs, e.g., one account may be usedfor P2P payments, one account may be used for general purchase, andanother account may be used just for a specific merchant 1019 who mightbe high risk in customer's perception. The customer 1001 is able to keeponly as much money as she wants in these accounts and is given theoption to set limits that help prevent fraud, e.g., maximum transactionamount, number of transactions in a day, etc.

These processes and systems lets customers of a financial entity sendpayments to anyone outside the financial entity, let non-financialentity customers open accounts with the financial entity through a viralaccount opening process, and provides customers the ability to makeP2P/P2M payments from an account that may be instantly funded.

As should be understood by those skilled in the art, variouscombinations and sub-combinations of the descriptions included hereinmay be utilized absent the illustrative example provided. For example,in accordance with one or more aspects of the present disclosure, thereis no requirement in place to mandate a user to open a master accountwith a financial entity before a sub-account may be opened. A personusing an account with a merchant that is linked to the financial entityis able to open a sub-account anytime without first having to apply fora master DDA with the financial entity. In such a situation, thesub-account is an account of the user in which the user does not haveother accounts affiliated with the financial entity. As such, themerchant, such as a media downloading web site, may have a link to opensuch a sub-account with the financial entity. In addition, a personreceiving payment who does not have a sub-account may open one to getaccess to those funds. A P2P/P2M account may be such an opened accountis a P2P/P2M account described herein may exist on its own.

While illustrative systems and methods as described herein embodyingvarious aspects of the present invention are shown, it will beunderstood by those skilled in the art, that the invention is notlimited to these embodiments. Modifications may be made by those skilledin the art, particularly in light of the foregoing teachings. Forexample, each of the elements of the aforementioned embodiments may beutilized alone or in combination or subcombination with elements of theother embodiments. It will also be appreciated and understood thatmodifications may be made without departing from the true spirit andscope of the present invention. The description is thus to be regardedas illustrative instead of restrictive on the present invention.

1. A method comprising: receiving a payment request from a paymentsender via a communication from a remote device, wherein the paymentrequest comprises an alias, wherein the alias is not a financial accountnumber, and wherein the payment sender is associated with a paymentsender's financial account; using a processor to identify a paymentrecipient's financial account based at least partially on the alias; andtransferring funds from the payment sender's financial account to thepayment recipient's financial account.
 2. The method of claim 1, whereinthe alias comprises an email address.
 3. The method of claim 1, whereinthe alias comprises a telephone number.
 4. The method of claim 1,wherein the alias comprises a mobile telephone number.
 5. The method ofclaim 1, wherein the alias comprises a social networking identification.6. The method of claim 1, wherein the payment recipient's financialaccount is associated with a payment recipient, and wherein the aliascomprises a unique identifier used generally by the public tocommunicate with the payment recipient.
 7. The method of claim 1,wherein using the processor to identify the payment recipient'sfinancial account based at least partially on the alias comprises:accessing a memory device comprising a data repository that maps aplurality of aliases back to one or more financial accounts; and usingthe data repository in combination with the alias to identify thepayment recipient's financial account.
 8. The method of claim 1, whereinusing the processor to identify the payment recipient's financialaccount based at least partially on the alias comprises: accessing amemory device comprising a data repository that maps each of a pluralityof aliases back to a financial account number; and using the datarepository in combination with the alias to identify the paymentrecipient's financial account number.
 9. The method of claim 1, furthercomprising: using the alias to contact an entity associated with thealias; and providing the entity with information about the paymentrequest.
 10. The method of claim 9, wherein the alias comprises atelephone number, email address, or social networking identification,and wherein using the alias to contact the entity associated with thealias further comprises: using the telephone number, email address, orsocial networking identification to send a communication regarding thepayment request.
 11. The method of claim 9, wherein the entity comprisesa payment recipient associated with the payment recipient's financialaccount.
 12. The method of claim 9, wherein the entity comprises aperson.
 13. The method of claim 9, wherein the entity comprises amerchant.
 14. The method of claim 1, wherein the payment recipient'sfinancial account comprises a bank account.
 15. The method of claim 1,wherein the payment sender's financial account comprises a bank account.16. The method of claim 1, wherein the payment recipient's financialaccount comprises a peer-to-peer or peer-to-merchant sub-account. 17.The method of claim 1, wherein the payment sender's financial accountcomprises a peer-to-peer or peer-to-merchant sub-account.
 18. The methodof claim 1, wherein transferring funds from the payment sender'sfinancial account to the payment recipient's financial accountcomprises: initiating an Automated Clearing House (ACH) transfer offunds from the payment sender's financial account to the paymentrecipient's financial account.
 19. The method of claim 1, whereintransferring funds from the payment sender's financial account to thepayment recipient's financial account comprises: initiating a directaccount-to-account transfer of funds from the payment sender's financialaccount to the payment recipient's financial account.
 20. The method ofclaim 19, wherein the direct account-to-account transfer of fundscomprises a substantially real-time transfer that does not use an ACHpayment network, or a credit or debit card payment network.
 21. Themethod of claim 1, further comprising: registering the alias byreceiving the alias from an entity and mapping, in a memory device, thealias back to the entity's financial account.
 22. The method of claim21, wherein registering the alias further comprises: verifying that thealias is associated with the entity.
 23. The method of claim 22, whereinthe alias comprises a telephone number, email address, or socialnetworking identification, and wherein verifying that the alias isassociated with the entity comprises initiating a communication with theentity using the alias.
 24. The method of claim 1, further comprising:using the alias to contact an entity; providing the entity with noticeof the payment request; and requesting that the entity register thealias as being associated with the entity's financial account.
 25. Themethod of claim 1, further comprising: using the alias to contact anentity; providing the entity with notice of the payment request; andrequesting that the entity open a new financial account so that theentity can receive funds from the payment request in the new financialaccount.
 26. The method of claim 1, wherein receiving the paymentrequest from the payment sender via the communication from the remotedevice comprises: receiving the payment request via a text message froma mobile phone.
 27. The method of claim 1, wherein receiving the paymentrequest from the payment sender via the communication from the remotedevice comprises: receiving the payment request via a communication froma mobile phone's banking application.
 28. The method of claim 1, whereinreceiving the payment request from the payment sender via thecommunication from the remote device comprises: receiving the paymentrequest via a communication from a personal computer device logged intothe payment sender's online banking account of an online bankingwebsite.
 29. An apparatus comprising: at least one communicationinterface configured to receive a payment request from a payment sendervia a communication from a remote device, wherein the payment requestcomprises an alias, wherein the alias is not a financial account number,and wherein the payment sender is associated with a payment sender'sfinancial account; at least one processor communicably coupled to the atleast one communication interface; and at least one memory communicablycoupled to the at least one processor and having stored thereonexecutable instructions that, when executed by the at least oneprocessor, cause the apparatus to: identify a payment recipient'sfinancial account based at least partially on the alias; and transferfunds from the payment sender's financial account to the paymentrecipient's financial account.
 30. The apparatus of claim 29, whereinthe alias comprises an email address.
 31. The apparatus of claim 29,wherein the alias comprises a telephone number.
 32. The apparatus ofclaim 29, wherein the alias comprises a mobile telephone number.
 33. Theapparatus of claim 29, wherein the alias comprises a social networkingidentification.
 34. The apparatus of claim 29, wherein the paymentrecipient's financial account is associated with a payment recipient,and wherein the alias comprises a unique identifier used generally bythe public to communicate with the payment recipient.
 35. The apparatusof claim 29, wherein the at least one memory further comprises: a datarepository that maps a plurality of aliases back to one or morefinancial accounts; and executable instructions that, when executed bythe at least one processor, cause the apparatus to identify the paymentrecipient's financial account based at least partially on the alias byusing the data repository in combination with the alias to identify thepayment recipient's financial account.
 36. The apparatus of claim 29,wherein the at least one memory further comprises: a data repositorythat maps each of a plurality of aliases back to a financial accountnumber; and executable instructions that, when executed by the at leastone processor, cause the apparatus to identify the payment recipient'sfinancial account based at least partially on the alias by using thedata repository in combination with the alias to identify the paymentrecipient's financial account number.
 37. The apparatus of claim 29,further comprising executable instructions stored in the at least onememory that, when executed by the at least one processor, cause theapparatus to: use the alias to contact an entity associated with thealias; and provide the entity with information about the paymentrequest.
 38. The apparatus of claim 37, wherein the alias comprises atelephone number, email address, or social networking identification,and wherein the executable instructions that cause the apparatus to usethe alias to contact the entity associated with the alias comprise:executable instructions that, when executed by the at least oneprocessor, cause the apparatus to use the telephone number, emailaddress, or social networking identification to send a communicationregarding the payment request.
 39. The apparatus of claim 37, whereinthe entity comprises a payment recipient associated with the paymentrecipient's financial account.
 40. The apparatus of claim 29, whereinthe payment recipient's financial account comprises a bank account. 41.The apparatus of claim 29, wherein the executable instructions thatcause the apparatus to transfer funds from the payment sender'sfinancial account to the payment recipient's financial account comprise:executable instructions that, when executed by the at least oneprocessor, cause the apparatus to initiate an Automated Clearing House(ACH) transfer of funds from the payment sender's financial account tothe payment recipient's financial account.
 42. The apparatus of claim29, wherein the executable instructions that cause the apparatus totransfer funds from the payment sender's financial account to thepayment recipient's financial account comprise: executable instructionsthat, when executed by the at least one processor, cause the apparatusto initiate a direct account-to-account transfer of funds from thepayment sender's financial account to the payment recipient's financialaccount, wherein the direct account-to-account transfer of fundscomprises a substantially real-time transfer that does not use an ACHpayment network, or a credit or debit card payment network.
 43. Theapparatus of claim 29, further comprising: executable instructionsstored in the at least one memory that, when executed by the at leastone processor, cause the apparatus to register the alias by receivingthe alias from an entity and mapping, in the at least one memory, thealias back to the entity's financial account.
 44. The apparatus of claim43, wherein the executable instructions that cause the apparatus toregister the alias further comprise: executable instructions that, whenexecuted by the at least one processor, cause the apparatus to verifythat the alias is associated with the entity.
 45. The apparatus of claim44, wherein the alias comprises a telephone number, email address, orsocial networking identification, and wherein the executableinstructions that cause the apparatus to verify that the alias isassociated with the entity comprise: executable instructions that, whenexecuted by the at least one processor, cause the apparatus to use theat least one communication interface to initiate a communication withthe entity using the alias.
 46. The apparatus of claim 29, furthercomprising executable instructions stored in the at least one memorythat, when executed by the at least one processor, cause the apparatusto: use the at least one communication interface and the alias tocontact an entity; provide the entity with notice of the paymentrequest; and request that the entity register the alias as beingassociated with the entity's financial account.
 47. The apparatus ofclaim 29, further comprising executable instructions stored in the atleast one memory that, when executed by the at least one processor,cause the apparatus to: use the at least one communication interface andthe alias to contact an entity; provide the entity with notice of thepayment request; and request that the entity open a new financialaccount so that the entity can receive funds from the payment request inthe new financial account.
 48. The apparatus of claim 29, wherein theremote device comprises a mobile phone, and wherein the at least onecommunication interface is configured to receive the payment requestfrom the payment sender via a text message from the mobile phone.
 49. Acomputer readable medium having computer executable instructions storedtherein, wherein the computer executable instructions comprise:instructions operable to receive a payment request from a payment sendervia a communication from a remote device, wherein the payment requestcomprises an alias, wherein the alias is not a financial account number,and wherein the payment sender is associated with a payment sender'sfinancial account; instructions operable to identify a paymentrecipient's financial account based at least partially on the alias; andinstructions operable to transfer funds from the payment sender'sfinancial account to the payment recipient's financial account.
 50. Thecomputer readable medium of claim 49, wherein the alias comprises anemail address.
 51. The computer readable medium of claim 49, wherein thealias comprises a telephone number.
 52. The computer readable medium ofclaim 49, wherein the alias comprises a mobile telephone number.
 53. Thecomputer readable medium of claim 49, wherein the alias comprises asocial networking identification.
 54. The computer readable medium ofclaim 49, wherein the payment recipient's financial account isassociated with a payment recipient, and wherein the alias comprises aunique identifier used generally by the public to communicate with thepayment recipient.
 55. The computer readable medium of claim 49, whereinthe instructions operable to identify the payment recipient's financialaccount based at least partially on the alias comprise: instructionsoperable to access a memory device comprising a data repository thatmaps a plurality of aliases back to one or more financial accounts; andinstructions operable to use the data repository in combination with thealias to identify the payment recipient's financial account.
 56. Thecomputer readable medium of claim 49, further comprising: instructionsoperable to use the alias to contact an entity associated with thealias; and instructions operable to provide the entity with informationabout the payment request.
 57. The computer readable medium of claim 49,wherein the payment recipient's financial account comprises a bankaccount.
 58. The computer readable medium of claim 49, furthercomprising: instructions operable to register the alias by receiving thealias from an entity and mapping, in a memory device, the alias back tothe entity's financial account.
 59. The computer readable medium ofclaim 58, wherein the instructions operable to register the aliasfurther comprise: instructions operable to verify that the alias isassociated with the entity.
 60. The computer readable medium of claim59, wherein the alias comprises a telephone number, email address, orsocial networking identification, and the instructions operable toverify that the alias is associated with the entity comprise:instructions operable to initiate a communication with the entity usingthe alias.
 61. The computer readable medium of claim 49, furthercomprising: instructions operable to use the alias to contact an entity;instructions operable to provide the entity with notice of the paymentrequest; and instructions operable to request that the entity registerthe alias as being associated with the entity's financial account. 62.The computer readable medium of claim 49, further comprising:instructions operable to use the alias to contact an entity;instructions operable to provide the entity with notice of the paymentrequest; and instructions operable to request that the entity open a newfinancial account so that the entity can receive funds from the paymentrequest in the new financial account.
 63. The computer readable mediumof claim 49, wherein the instructions operable to receive the paymentrequest from the payment sender via the communication from the remotedevice comprise: instructions operable to receive the payment requestvia a text message from a mobile phone.
 64. A method of making apayment, the method comprising: sending a communication from a paymentsender to a remote device, wherein the communication comprises a paymentrequest and an alias, wherein the alias is not a financial accountnumber, wherein the payment sender is associated with a payment sender'sfinancial account, and wherein the remote device identifies a paymentrecipient's financial account based at least partially on the alias andthen transfers funds from the payment sender's financial account to thepayment recipient's financial account.
 65. The method of claim 64,wherein the remote device comprises a network server.
 66. The method ofclaim 64, comprising: sending the communication from a mobile phone. 67.The method of claim 64, wherein the communication comprises a textmessage from a mobile device.
 68. The method of claim 64, wherein thealias comprises a telephone number, email address, or social networkingidentifier.